In the last lesson, we published, version one of our up to GitHub as a release.
So in this lesson, let's see how to add electron boulders, auto update a module to our app in order
to make use of published app releases.
We've already covered why we're using Electron Baldies Auto Update a module in a previous lesson.
But to recap, electrons own auto updater requires a dedicated release server, something to avoid in
favor of simple maintenance, free get up releases or any of the other providers.
OK, over on the auto update guide of the Electron Build Docs.
A bit further down we see this quick set up guide with the very first step being to install the electron
updater module.
This is, of course, as the electron build a toolset runs outside of our app performing the bold publishing,
etc..
So in order to make the auto update a module part of our app, we have to install it as a project dependency
over to the terminal and still in the project directory run npm ei electron updater, the name of that
module or through this Undun check packaged on Jason to make sure this was added as a dependency.
And there so having the electron update a module available in our project, we can now require that
auto updater from it.
Back in the docs.
Copy this require statement here and what I'll do is again add all the update logic in a separate local
module.
I'll call this updater.
Require the module before creating it.
Const updater equals require current directory updater doges or just updater create that file in the
main project directory updated or JS in which we can start by requiring electron baldies auto update
a module as we copied it from the docs.
This module will export a single function with which to initialize the update process, that function
being assigned to this updater variable in mind.
So when we say this function will initialize the update process, that essentially means to check for
and apply any available updates, assigning to module exports a function.
In which the first thing to do will be to check for any available updates, GitHub releases.
I'll just use a log for now to test.
Checking for updates.
And to run this updater module, we can call it after the app has been launched, keep in mind there's
no rush to do this immediately.
So in Maine, always, let's say, inside of the create window function as that only runs when the app
is ready.
Check for app updates after, say, three seconds.
So set time out.
Calling updater.
This variable here, as we're exporting a single function after three seconds, right, save this to
make sure everything is firing and PM start to launch the app.
Quickly switch back to the terminal and they're three seconds later, we get the message from the updater
module, so everything is working.
OK, let's implement the real update.
Check then back to the electron build docs.
And the first thing to now consider is the notice we have right at the top of this guide here.
Mac OS must be code signed for auto updates to work, meaning that we'll have to add the update code,
build the app and launch the final standalone app in order to test auto updates.
The problem being that a Bolt app isn't running from a terminal window.
So long message won't be available.
This is a bit of a problem for testing and knowing whether everything is working as expected.
So to debug the auto update, a module will also have to enable logging to a file in this auto update
guides table of contents.
Then on the right here we see debugging.
Go there.
This two lines of code that allows the auto update a module to log to a file using another module electron
log.
I'll copy these two lines to add to the updater module.
First thing after requiring the auto update, a module enable logging with electron log to break this
down, we are setting the auto updater modules, internal logs to be electron log, which will install
in a second and configuring it to log to a file with a log level of info.
This can also be said to debug for more detailed logs.
Install this log module we're requiring here.
I'll install it as a production dependency for now.
But you could also just remove logging entirely in a production up npm ie electron log forward through
this and done.
OK, so we now have logging enabled for the auto update a module, but we're still not actually doing
anything that would cause it to log.
So let's start by checking for any available updates.
Again, in the table of contents.
We have this API section, so navigate there and the first method will want to use from the auto update
a module is this check for updates.
Copy this.
Back to updated Hodgers, where we can replace this log message with auto update, dot check for updates,
this call to check for updates will now log its findings as per this configuration.
But where will it be logged to?
This log fire location will be different for each platform.
So to find the location, check the electron log module back in the debugging section.
This link here.
The module repo, where in the readme we have these paths, the default log path for Linux, Mac and
Windows, I'll copy the Mac path to check my bold.
Over to the terminal, print the contents of the log file with CAT and that file path replacing the
app name Placeholder with the production name of the app IT.
And process being main enter and of course, that file doesn't yet exist as we've not actually logged
anything to it, but this is the path that will be at OK to test this, then we have to rebuild our
app to include the new updated code.
I'll just rebuild for Mac at the same version as our existing release version one meaning that an update
won't be found as the update is the same version as this bold.
But we'll still be checking for it, of course.
Forward through this and done.
I'll just use the unpacked version to test.
Keeping in mind what will happen, the app will fire its ready event after being launched that calls
create a window in which we start a timeout to call the update module with our update code after three
seconds, at which point the app will, of course, be completely ready.
Launch.
Wait for three seconds to ensure that updater module has checked for updates along with the app, check
the log file again.
And there is one simple message checking for update, no update would have been found, of course,
and as mentioned, if you need to see more detailed information about what happened here, you can simply
change the log level to debug or silly to see absolutely everything.
OK, so not finding an update is rather uninteresting, but is the expected behavior.
So let's now rebuild the same app again, but at a lower version than our published release in Package
Dot.
Jason, we can just update the version here to build at a different version.
Our published release is one point zero point zero.
So make this version nought point nine.
Save this and rebuild as before.
Done over to the desk directly still from this unpacked target launch, what is now version nought point
nine, we can confirm that from the about menu.
Yeah, so the auto update should recognize the published release as a viable update that updates should
have been run by now, so quit and check the logs again.
And there this year being our original check log where nothing was found, but this time around we get
found version one and the module automatically started downloading that update.
This is, of course, not very informative for the end user.
So in the next lesson, will handle this update found prompt the user to update and manually download
and install it.